Selenium Architecture describes how Selenium components communicate with each other to automate web browsers and execute automated test cases. Understanding Selenium Architecture is important because it explains how a Selenium test script sends commands, how those commands reach the browser, how the browser performs the requested action, and how the response is returned to the test script.
Selenium is not a single tool. It is an umbrella project containing multiple tools and libraries, with Selenium WebDriver being the primary API used for modern browser automation. WebDriver provides a language-neutral interface for controlling browsers through browser-specific WebDriver implementations.
For learners interested in structured Selenium automation training, you can explore the JustAcademy Selenium Training Course and Register for Selenium Course Demo.
Selenium Architecture is the internal communication structure through which Selenium test code interacts with a web browser. A typical Selenium automation flow involves the test script, Selenium language bindings, WebDriver, a browser-specific driver or browser automation implementation, and the actual browser.
The basic communication flow can be represented as:
Test Script
|
v
Selenium WebDriver API
|
v
Browser Driver / WebDriver Implementation
|
v
Web Browser
|
v
Web Application
When a test script executes a command such as driver.get(), driver.findElement(), or driver.click(), Selenium processes the requested operation through the WebDriver interface. The browser-side WebDriver implementation receives the command, performs the required action, and returns a response.
Understanding architecture helps automation testers understand what happens behind every Selenium command.
A modern Selenium automation setup can contain several important components.
| Component | Purpose |
|---|---|
| Test Script | Contains automation instructions written using Java, Python, C#, JavaScript, Ruby, or another supported language. |
| Selenium Language Binding | Provides programming-language-specific APIs used by the test script. |
| WebDriver API | Provides a standard interface for browser automation. |
| Browser Driver / WebDriver Implementation | Handles communication between WebDriver commands and the target browser. |
| Browser | Executes the requested browser actions. |
| Web Application | The application being tested. |
| Selenium Grid | Provides remote and distributed execution across browsers and machines. |
+---------------------------+
| Test Script |
| Java / Python |
+-------------+-------------+
|
v
+---------------------------+
| Selenium Language |
| Binding |
+-------------+-------------+
|
v
+---------------------------+
| WebDriver API |
+-------------+-------------+
|
v
+---------------------------+
| Browser Driver / WebDriver|
| Implementation |
+-------------+-------------+
|
v
+---------------------------+
| Browser |
| Chrome / Firefox / Edge |
+-------------+-------------+
|
v
+---------------------------+
| Web Application |
+---------------------------+
The architecture separates test code from browser-specific implementation. This allows automation code to use a common WebDriver API while the appropriate browser implementation handles browser-specific communication.
Selenium WebDriver is the primary Selenium component used for modern browser automation. It provides APIs that allow a test program to control a browser and perform actions that correspond to user interactions.
WebDriver supports operations such as:
WebDriver API is the programming interface used by Selenium test scripts.
For example, in Java:
WebDriver driver = new ChromeDriver();
driver.get("https://example.com");
String title = driver.getTitle();
System.out.println(title);
driver.quit();
Here, WebDriver is the interface and ChromeDriver is a browser-specific WebDriver implementation used to automate Chrome.
Selenium provides language-specific bindings that allow developers to write automation scripts using supported programming languages.
| Language | Typical Selenium Usage |
|---|---|
| Java | Widely used for enterprise automation frameworks and TestNG/JUnit projects. |
| Python | Commonly used for automation, scripting, and testing. |
| C# | Frequently used in Microsoft/.NET environments. |
| JavaScript | Used with JavaScript and Node.js automation environments. |
| Ruby | Supported for Selenium browser automation. |
A browser-specific WebDriver implementation enables communication between Selenium commands and the target browser.
Examples include:
The implementation details are browser-specific, while Selenium provides a consistent WebDriver API to the test developer.
Java Test
|
v
Selenium Java Binding
|
v
WebDriver API
|
v
Chrome WebDriver Implementation
|
v
Google Chrome
|
v
Web Application
Example:
WebDriver driver = new ChromeDriver();
driver.get("https://example.com");
driver.findElement(By.id("login")).click();
driver.quit();
The developer does not need to manually implement browser protocol communication. Selenium and the browser-specific implementation handle the communication.
Java Test
|
v
Selenium Java Binding
|
v
WebDriver API
|
v
Firefox WebDriver Implementation
|
v
Mozilla Firefox
|
v
Web Application
Example:
WebDriver driver = new FirefoxDriver();
driver.get("https://example.com");
System.out.println(driver.getTitle());
driver.quit();
Java Test
|
v
Selenium Java Binding
|
v
WebDriver API
|
v
Edge WebDriver Implementation
|
v
Microsoft Edge
|
v
Web Application
Example:
WebDriver driver = new EdgeDriver();
driver.get("https://example.com");
System.out.println(driver.getCurrentUrl());
driver.quit();
When a Selenium test executes a command, the command must travel from the test code to the browser environment.
For example:
driver.get("https://example.com");The conceptual flow is:
Test Code
|
| get()
v
WebDriver API
|
v
WebDriver Command
|
v
Browser WebDriver Implementation
|
v
Browser
|
v
Open Requested URL
|
v
Response
|
v
Test Code
Modern Selenium WebDriver communication is based on the W3C WebDriver standard. The protocol defines a standardized way for automation clients and browser implementations to communicate.
This standardization provides a common protocol for browser automation instead of requiring every test script to understand browser-specific internal communication details.
Selenium Client
|
| W3C WebDriver Commands
v
Browser WebDriver Implementation
|
v
Browser
|
v
Web Application
Older Selenium versions used the JSON Wire Protocol. Modern Selenium uses the W3C WebDriver standard.
| Feature | JSON Wire Protocol | W3C WebDriver |
|---|---|---|
| Usage | Legacy Selenium communication model. | Modern standardized WebDriver protocol. |
| Status | Legacy. | Current standard approach. |
| Standardization | Selenium-specific protocol. | W3C standard. |
| Modern Selenium | Not the primary protocol. | Primary WebDriver communication model. |
Consider the following test:
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
public class LoginTest {
public static void main(String[] args) {
WebDriver driver = new ChromeDriver();
driver.get("https://example.com");
System.out.println(driver.getTitle());
driver.quit();
}
}
The architecture behind this program is:
LoginTest.java
|
v
WebDriver Interface
|
v
ChromeDriver
|
v
Chrome Browser
|
v
Example Web Application
Selenium 4 uses the W3C WebDriver standard and provides a modernized architecture for browser automation. Selenium Grid 4 also provides a component-based architecture designed for remote, distributed, and parallel execution.
Grid allows WebDriver scripts to execute against remote browser instances and supports execution across multiple machines, browser versions, and platforms.
Selenium Grid becomes important when test execution needs to move beyond a single local browser or machine.
Grid can be used for:
Selenium Grid 4 consists of several components including Router, New Session Queue, Distributor, Node, Session Map, and Event Bus.
| Component | Responsibility |
|---|---|
| Router | Acts as the front entry point for Grid requests and routes them to the appropriate component. |
| New Session Queue | Maintains incoming new session requests until a suitable slot is available. |
| Distributor | Maintains knowledge of available slots and assigns new sessions to suitable Nodes. |
| Node | Runs WebDriver sessions and provides browser execution capacity. |
| Session Map | Maps session IDs to the Nodes where those sessions are running. |
| Event Bus | Provides asynchronous communication between Grid components. |
+----------------------+
| Test Script |
| Java / Python / C# |
+----------+-----------+
|
v
+----------------------+
| RemoteWebDriver |
+----------+-----------+
|
v
+----------------------+
| Router |
+----------+-----------+
|
+-------------+-------------+
| |
v v
+----------------+ +----------------+
| New Session | | Existing |
| Queue | | Session |
+-------+--------+ +--------+-------+
| |
v v
+----------------+ +----------------+
| Distributor | | Session Map |
+-------+--------+ +----------------+
|
v
+----------------+
| Node |
+-------+---------+
|
+-------+-------+
| | |
v v v
Chrome Firefox Edge
| | |
+-------+-------+
|
v
Web Application
The Router is the entry point of Selenium Grid. It receives incoming requests and determines where those requests should be sent.
For a new session request, the Router forwards the request toward the New Session Queue. For an existing session, the Router can use the Session Map to determine which Node owns that session and forward the command accordingly.
Client
|
v
Router
|
+---- New Session ------> New Session Queue
|
+---- Existing Session -> Session Map -> Node
The New Session Queue stores incoming browser-session requests that have not yet been assigned to a suitable Node.
For example, if multiple tests request browsers simultaneously but all suitable slots are currently occupied, requests can wait in the session queue until capacity becomes available.
Test 1 ----\
Test 2 -----\
Test 3 ------> Router ---> New Session Queue ---> Distributor
Test 4 -----/
Test 5 ----/
The Distributor is responsible for finding an appropriate execution slot for a new session.
It maintains information about available locations and slots in the Grid and uses requested capabilities to determine where a session can run.
New Session Request
|
v
Distributor
|
+---- Chrome Slot
|
+---- Firefox Slot
|
+---- Edge Slot
|
+---- Other Matching Slot
A Node is the component that actually runs WebDriver sessions.
A Node can provide one or more slots. A slot represents a place where a browser session can run. Selenium Grid uses slot capabilities to determine whether a requested session can be assigned to a particular slot.
Node
|
+---- Chrome Slot
|
+---- Firefox Slot
|
+---- Edge Slot
|
+---- Chrome Slot
The Session Map maintains the relationship between a running session ID and the Node where that session is executing.
For example:
Session ID A ---> Node 1
Session ID B ---> Node 2
Session ID C ---> Node 3
When a command belongs to an existing session, Grid can use this mapping to route the command to the appropriate Node.
The Event Bus provides asynchronous communication between Grid components.
It can be thought of as a messaging mechanism through which Grid components can publish and receive events.
Node
|
| Event / Heartbeat
v
Event Bus
|
+---- Distributor
|
+---- Other Grid Components
quit(), the browser session is terminated and the slot becomes available again.| Feature | Local WebDriver | Selenium Grid |
|---|---|---|
| Execution | Usually local. | Remote or distributed. |
| Machine | Usually one machine. | Can involve multiple machines. |
| Browser Testing | Local browsers. | Browsers available on Grid Nodes. |
| Parallel Execution | Possible with suitable setup. | Designed for scalable parallel execution. |
| Cross Platform | Limited to available local environment. | Can combine different operating systems and environments. |
| Remote Execution | Not the primary purpose. | Core capability. |
RemoteWebDriver is used when the browser session needs to be created on a remote Selenium server or Grid instead of directly on the local machine.
Example:
import java.net.MalformedURLException;
import java.net.URL;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
public class RemoteTest {
public static void main(String[] args) throws MalformedURLException {
URL gridUrl = new URL("http://localhost:4444");
ChromeOptions options = new ChromeOptions();
WebDriver driver =
new RemoteWebDriver(gridUrl, options);
driver.get("https://example.com");
System.out.println(driver.getTitle());
driver.quit();
}
}
Test Machine
|
| RemoteWebDriver
v
Selenium Grid
|
v
Router
|
v
Distributor
|
v
Node
|
v
Browser
|
v
Web Application
The test code can remain on one machine while the browser executes on another machine.
Standalone mode combines the required Grid components into a single process and is useful for learning, local testing, and simple Grid environments.
java -jar selenium-server-.jar standalone The default Grid endpoint is commonly:
http://localhost:4444For this setup, the environment should have a compatible Java runtime, installed browsers, the Selenium Server JAR, and appropriate browser-driver management/configuration.
In a Hub and Node deployment, the Hub provides the central entry point and coordinates browser sessions, while Nodes provide browser execution capacity.
+----------------+
| Hub |
|----------------|
| Router |
| Distributor |
| Session Map |
| Session Queue |
| Event Bus |
+-------+--------+
|
+--------------+--------------+
| | |
v v v
+---------+ +---------+ +---------+
| Node 1 | | Node 2 | | Node 3 |
| Chrome | | Firefox | | Edge |
+---------+ +---------+ +---------+
This deployment can combine different machines, operating systems, and browser configurations into a single Grid environment.
In a distributed deployment, Grid components can be separated across machines or containers instead of running everything as a single process.
+----------------+
| Router |
+-------+--------+
|
v
+----------------+
| Session Queue |
+-------+--------+
|
v
+----------------+
| Distributor |
+-------+--------+
|
+--------------+--------------+
| | |
v v v
Node 1 Node 2 Node 3
Chrome Firefox Edge
This architecture can be useful when automation infrastructure requires greater separation and scalability.
Browser capabilities describe the environment and browser characteristics requested by a test.
Modern Selenium Java code commonly uses browser-specific Options classes.
ChromeOptions options = new ChromeOptions();
options.addArguments("--start-maximized");
WebDriver driver =
new RemoteWebDriver(gridUrl, options);
FirefoxOptions options = new FirefoxOptions();
WebDriver driver =
new RemoteWebDriver(gridUrl, options);
EdgeOptions options = new EdgeOptions();
WebDriver driver =
new RemoteWebDriver(gridUrl, options);
Grid needs to determine whether a Node can satisfy the requirements of a new browser session.
A simplified request might specify:
{
"browserName": "chrome",
"platformName": "windows"
}
The Grid compares requested capabilities with available slots.
Requested:
Chrome + Windows
Available:
Node 1 -> Chrome + Windows
Node 2 -> Firefox + Windows
Node 3 -> Edge + Windows
Matching Node:
Node 1
A Grid slot represents a place where a session can run and has capabilities that can be matched against session requests.
Selenium Architecture makes it possible to build a test suite that executes the same functional scenario across different browsers.
Test Suite
|
+-------------+-------------+
| | |
v v v
Chrome Firefox Edge
| | |
v v v
Node 1 Node 2 Node 3
| | |
+-------------+-------------+
|
v
Test Results
Parallel execution means multiple independent tests or browser sessions can execute at the same time.
Test Suite
|
+-----------+-----------+
| | |
v v v
Test 1 Test 2 Test 3
| | |
v v v
Node 1 Node 2 Node 3
| | |
Chrome Firefox Edge
Parallel execution can reduce overall execution time when the tests and infrastructure are designed correctly.
TestNG is commonly used with Selenium to organize test cases, manage suites, perform parameterization, and support parallel test execution.
Example:
import org.testng.annotations.Test;
public class LoginTest {
@Test
public void validLoginTest() {
System.out.println("Valid login test");
}
@Test
public void invalidLoginTest() {
System.out.println("Invalid login test");
}
}
The execution architecture can be:
TestNG
|
+---- Test 1 ---> Selenium ---> Browser
|
+---- Test 2 ---> Selenium ---> Browser
|
+---- Test 3 ---> Selenium ---> Browser
Maven can be used to manage Selenium project dependencies and execute automated test projects.
A typical project structure is:
SeleniumProject/
|
+-- pom.xml
|
+-- src/
|
+-- test/
|
+-- java/
|
+-- tests/
| +-- LoginTest.java
|
+-- pages/
+-- LoginPage.java
The architecture can be expanded with TestNG, Page Object Model, reporting, logging, and Grid.
+----------------------+
| Test Cases |
+----------+-----------+
|
v
+----------------------+
| TestNG |
+----------+-----------+
|
v
+----------------------+
| Selenium WebDriver |
+----------+-----------+
|
v
+----------------------+
| RemoteWebDriver / |
| Local WebDriver |
+----------+-----------+
|
+------------+------------+
| |
v v
Local Browser Selenium Grid
|
v
Router
|
v
Distributor
|
+------------+------------+
| | |
v v v
Node 1 Node 2 Node 3
Chrome Firefox Edge
| | |
+------------+------------+
|
v
Web Application
In local execution, the test and browser are generally available on the same machine.
Developer Machine
|
+-- Java Test
|
+-- Selenium
|
+-- Browser Driver / Browser WebDriver Implementation
|
+-- Chrome / Firefox / Edge
|
+-- Web Application
This setup is useful for development and debugging.
In remote execution, the test machine sends WebDriver commands to a remote Selenium server or Grid.
Machine A
Test Code
|
| RemoteWebDriver
|
v
Machine B
Selenium Grid
|
v
Browser
|
v
Application
| Feature | Local WebDriver | RemoteWebDriver |
|---|---|---|
| Browser Location | Usually local. | Remote environment. |
| Typical Usage | Development and local testing. | Grid and remote testing. |
| Grid Required | No. | Usually a remote WebDriver server or Grid endpoint. |
| Distributed Testing | Limited. | Supported. |
| Cross-Machine Testing | Not the primary purpose. | Yes. |
Every browser automation operation involves communication between the client and browser environment.
For example:
driver.findElement(By.id("username")).sendKeys("admin");Conceptual flow:
Java Test
|
v
Selenium API
|
v
WebDriver Command
|
v
Browser WebDriver Implementation
|
v
Browser
|
v
Find Element
|
v
Enter Text
|
v
Response
|
v
Java Test
Modern Selenium includes Selenium Manager, which can help automate browser driver and browser management. In supported scenarios, Selenium bindings can use Selenium Manager for driver management.
This reduces the need for developers to manually download and configure browser drivers in many standard setups.
However, the browser itself still needs to be available in the execution environment, and enterprise or custom environments may require explicit configuration.
One major benefit of WebDriver architecture is that test code can use a common WebDriver API while browser-specific implementations handle differences between browsers.
Common WebDriver API
|
+------------+------------+
| | |
v v v
Chrome Firefox Edge
Driver Driver Driver
| | |
v v v
Chrome Firefox Edge
Grid can be used to combine machines with different operating systems and browser configurations.
| Node | Operating System | Browser |
|---|---|---|
| Node 1 | Windows | Chrome |
| Node 2 | Linux | Firefox |
| Node 3 | macOS | Safari |
The exact browser and operating-system combinations available depend on the machines and Grid environment configured by the organization.
Selenium Grid can be integrated into CI/CD systems so that automated browser tests execute as part of a software delivery pipeline.
Developer
|
v
Git Repository
|
v
CI/CD Pipeline
|
v
Build
|
v
TestNG / JUnit
|
v
Selenium WebDriver
|
v
Selenium Grid
|
+---- Chrome
+---- Firefox
+---- Edge
|
v
Test Results
|
v
Reports
Page Object Model can be combined with Selenium architecture to separate page-specific interactions from test logic.
Test Layer
|
v
Page Object Layer
|
v
Selenium WebDriver
|
v
Grid / Browser
|
v
Web Application
Example:
public class LoginPage {
private WebDriver driver;
private By username =
By.id("username");
private By password =
By.id("password");
private By loginButton =
By.id("login");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void login(String user, String pass) {
driver.findElement(username).sendKeys(user);
driver.findElement(password).sendKeys(pass);
driver.findElement(loginButton).click();
}
}
When tests run in parallel, each test thread should generally have its own WebDriver instance. Sharing a single WebDriver instance across unrelated parallel tests can cause commands and browser state to interfere with each other.
A common Java approach is ThreadLocal.
public class DriverManager {
private static ThreadLocal driver =
new ThreadLocal<>();
public static void setDriver(WebDriver webDriver) {
driver.set(webDriver);
}
public static WebDriver getDriver() {
return driver.get();
}
public static void removeDriver() {
driver.remove();
}
}
Conceptual architecture:
Thread 1 ---> WebDriver 1 ---> Browser 1
Thread 2 ---> WebDriver 2 ---> Browser 2
Thread 3 ---> WebDriver 3 ---> Browser 3
Test isolation means that one test should not unintentionally affect another test.
Good test isolation includes:
A scalable automation architecture should allow additional browser capacity to be introduced without redesigning the entire test suite.
Initial Infrastructure
Tests
|
v
Grid
|
+---- Node 1
Expanded Infrastructure
Tests
|
v
Grid
|
+---- Node 1
+---- Node 2
+---- Node 3
+---- Node 4
Grid supports parallel execution and distributed browser infrastructure.
This can occur when the requested browser configuration cannot be matched by the available execution environment.
This commonly indicates that the Selenium server or Grid endpoint is not running or is not reachable at the configured address.
The requested browser may not be installed or available on the selected Node.
The requested browser or platform capabilities may not match any available Grid slot.
Another service may already be using a port required by the Selenium server or Grid configuration.
A Node may fail to become usable if it cannot communicate correctly with the Grid components.
Tests can interfere with each other if they share browser sessions, data, files, or other mutable resources.
| Problem | Possible Check |
|---|---|
| Grid unavailable | Check whether the Selenium server or Grid process is running. |
| Connection refused | Verify Grid URL, port, network connectivity, and server status. |
| Session creation failure | Check browser capabilities and available Node slots. |
| Browser not found | Check browser installation on the Node. |
| Driver issue | Check browser WebDriver implementation and Selenium Manager/environment configuration. |
| Tests interfere | Use independent WebDriver sessions and isolated test data. |
| Slow execution | Check Node capacity, browser startup time, network latency, and test synchronization. |
quit().Consider an e-commerce application that must be tested on Chrome, Firefox, and Edge.
The organization can create an automation architecture like:
Git Repository
|
v
CI Pipeline
|
v
TestNG
|
v
Selenium Tests
|
v
RemoteWebDriver
|
v
Selenium Grid
|
+-------------+-------------+
| | |
v v v
Node 1 Node 2 Node 3
Chrome Firefox Edge
| | |
+-------------+-------------+
|
v
E-Commerce App
|
v
Test Reports
Create a Selenium automation framework that executes a login test across multiple browsers using Selenium Grid.
CrossBrowserAutomation/
|
+-- pom.xml
|
+-- testng.xml
|
+-- src/
+-- main/
| +-- java/
| +-- pages/
| +-- LoginPage.java
| +-- utils/
| +-- DriverFactory.java
|
+-- test/
+-- java/
+-- tests/
+-- LoginTest.java
import java.net.MalformedURLException;
import java.net.URL;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.firefox.FirefoxOptions;
import org.openqa.selenium.edge.EdgeOptions;
import org.openqa.selenium.remote.RemoteWebDriver;
public class DriverFactory {
public static WebDriver createDriver(String browser)
throws MalformedURLException {
URL gridUrl =
new URL("http://localhost:4444");
switch (browser.toLowerCase()) {
case "chrome":
return new RemoteWebDriver(
gridUrl,
new ChromeOptions());
case "firefox":
return new RemoteWebDriver(
gridUrl,
new FirefoxOptions());
case "edge":
return new RemoteWebDriver(
gridUrl,
new EdgeOptions());
default:
throw new IllegalArgumentException(
"Unsupported browser: " + browser);
}
}
}
import org.openqa.selenium.WebDriver;
import org.testng.annotations.Test;
public class LoginTest {
@Test
public void loginTest() throws Exception {
WebDriver driver =
DriverFactory.createDriver("chrome");
try {
driver.get("https://example.com");
System.out.println(
driver.getTitle());
} finally {
driver.quit();
}
}
}
Selenium Architecture describes how Selenium test scripts communicate with browsers through WebDriver APIs, browser-specific WebDriver implementations, and, when applicable, Selenium Grid.
WebDriver is Selenium's browser automation API that provides a standard interface for controlling web browsers.
A browser driver or browser-specific WebDriver implementation enables Selenium to communicate with a particular browser.
RemoteWebDriver is used to create and control browser sessions through a remote WebDriver server or Selenium Grid.
Selenium Grid is used for remote, parallel, cross-browser, and distributed execution of WebDriver tests.
The Router acts as the front entry point for Grid requests and routes requests to the appropriate Grid component.
The Distributor determines which available Grid slot can satisfy a new session request.
A Node provides browser execution capacity and runs WebDriver sessions.
A slot represents a place where one browser session can run and has capabilities that can be matched against session requests.
The Session Map maintains the relationship between a session ID and the Node where that session is running.
It stores new session requests that have not yet been assigned to a suitable Node.
The Event Bus provides asynchronous communication between Grid components.
In local execution the browser generally runs on the test machine. In remote execution the test sends WebDriver commands to a remote browser environment.
Grid is used when automation needs remote execution, parallel execution, cross-browser testing, cross-platform testing, or distributed browser infrastructure.
Modern Selenium WebDriver uses the W3C WebDriver standard.
WebDriver provides browser automation APIs, while Grid provides infrastructure for routing WebDriver sessions to remote browser environments.
Separate instances prevent browser commands and state from different tests from interfering with each other.
A new session request can remain pending until a suitable slot becomes available or the request eventually fails according to the configured behavior.
Cross-browser testing verifies application behavior across different supported browsers such as Chrome, Firefox, and Edge.
Cross-platform testing verifies application behavior across different operating systems or execution environments.
Test Script
|
v
Selenium Binding
|
v
WebDriver API
|
v
Browser Driver / WebDriver Implementation
|
v
Browser
|
v
Web Application
For remote execution:
Test Script
|
v
RemoteWebDriver
|
v
Grid Router
|
v
New Session Queue
|
v
Distributor
|
v
Node
|
v
Browser
|
v
Web Application
After studying Selenium Architecture, learners should be able to:
Selenium Architecture explains the complete communication path between an automation test and the browser. A Selenium test typically starts with a programming-language binding and WebDriver API. The command is then handled by the appropriate browser WebDriver implementation and executed by the browser.
For local testing, this architecture can remain relatively simple. When testing requirements grow, Selenium Grid provides remote and distributed execution capabilities. Selenium Grid 4 uses components such as Router, New Session Queue, Distributor, Node, Session Map, and Event Bus to coordinate browser sessions and distribute execution across available infrastructure.
A strong understanding of Selenium Architecture helps testers build maintainable automation frameworks, troubleshoot failures, execute tests remotely, perform cross-browser testing, and scale test execution through parallel and distributed environments.
Learn Selenium automation, WebDriver, TestNG, Page Object Model, cross-browser testing, Selenium Grid, and automation framework concepts through the JustAcademy Selenium Training Course.
For course information and a demo session, visit Register for Selenium Course Demo.
SELENIUM AUTOMATION
|
v
+----------------------+
| Test Code |
| Java / Python / C# |
+----------+-----------+
|
v
+----------------------+
| Selenium Language |
| Binding |
+----------+-----------+
|
v
+----------------------+
| Selenium WebDriver |
| API |
+----------+-----------+
|
+------------+------------+
| |
v v
Local WebDriver RemoteWebDriver
| |
v v
Browser Selenium Grid
|
v
Router
|
+----------------+----------------+
| |
v v
New Session Queue Session Map
| |
v v
Distributor Existing
| Session
v |
Node <-------------------------------+
|
+-------------+-------------+
| | |
v v v
Chrome Firefox Edge
| | |
+-------------+-------------+
|
v
Web Application
|
v
Test Results
